src/components/Bubble.tsx (1)

24-47: arrivals 의존성으로 7초마다 오버레이 전체 재마운트 가능성 (선택적 리팩터)

useBusArrivals가 7초마다 refetch하면서 arrivals 객체가 갱신될 때마다 이 useEffect가 다시 실행되고, 내부에서 clearExisting() → 새 overlay 생성 흐름이라, 도착 정보가 갱신될 때마다 오버레이가 언마운트/리마운트되는 플리커가 발생할 여지가 있습니다. 체감상 문제가 된다면:

• 오버레이 생성/제거는 stop, onClose만 의존하는 이펙트로 두고,
• 내부 내용은 별도 React 컴포넌트로 빼서 arrivals를 props로 넘겨 일반적인 리렌더링만 일어나게 하거나,
• 전역(예: window.__currentBubbleOverlay)에 root를 캐싱해 두고 동일 overlay 위에서만 root.render를 다시 호출

하는 방향으로 분리해 보면 좋겠습니다. 급한 이슈는 아니라 optional refactor로 봐도 될 것 같습니다.

Also applies to: 270-291

src/api/bus.ts (1)

30-67: 도착 정보 타입/훅 설계는 명확하나, 필요 시 쿼리 활성화 제어 옵션 고려 권장

ArrivalBus / ArrivalStop / ArrivalsResponse로 도착 정보를 명시적으로 모델링하고, useBusArrivals에서 ArrivalsResponse | null을 반환하는 구조는 타입 측면에서 깔끔합니다. 다만 현재 구현대로면 Bubble 컴포넌트에서 이 훅을 사용하는 동안(오버레이가 닫혀 있어도) 7초마다 항상 도착 정보 API가 호출될 수 있습니다.

향후 트래픽이나 성능 이슈가 보이면:

• useBusArrivals(enabled: boolean, onError?: ...)처럼 enabled 플래그를 인자로 받게 하고,
• 내부 useQuery에 enabled 옵션을 전달하거나,
• 혹은 쿼리 키에 정류장 정보 등을 포함해 필요한 경우에만 구독하도록

조정할 수 있도록 설계 여지를 열어 두는 것도 좋을 것 같습니다. 지금 단계에서는 선택적 리팩터로 봐도 될 것 같습니다.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: KwonDeaGeun
Repo: KwonDeaGeun/WhatTheBus-Web PR: 21
File: src/App.tsx:16-23
Timestamp: 2025-09-22T04:45:54.455Z
Learning: KwonDeaGeun은 TypeScript에서 any 타입 사용을 피하고 더 타입 안전한 코드를 선호한다.

src/api/bus.ts (2)

24-27: 위치(7초)와 도착(30초) refetch 주기 차이가 의도된 설계인지 점검 제안

useBusLocations는 7초, useBusArrivals는 30초로 refetch 주기가 다르게 잡혀 있습니다. 실시간성이 더 중요한 쪽에 맞춘 의도된 값이라면 그대로 두어도 되지만, 둘을 동일 주기로 맞추는 것이 목표였다면 상수로 추출해서 공유하거나 주기를 명시적으로 설명하는 주석을 남겨 두면 유지보수 관점에서 더 명확해질 것 같습니다.

---

48-67: useBusArrivals의 에러 처리 및 null 처리에 대한 소소한 개선 제안

현재 try/catch에서 에러를 모두 처리하고 null을 반환하기 때문에 React Query 입장에서는 항상 “성공 + data가 null일 수 있음” 상태가 되고, isError/error는 사용되지 않게 됩니다. 이 패턴을 의도하신 것이라면 괜찮지만, 훅을 소비하는 쪽에서 React Query의 에러 상태를 활용하고 싶다면 onError 콜백 호출 후에 에러를 그대로 throw하는 쪽도 고려해 볼 수 있습니다. 또한,

return data || null;

보다는

-                const data = await apiGet<ArrivalsResponse>(
-                    API_ENDPOINTS.BUS.ARRIVALS
-                );
-                return data || null;
+                const data = await apiGet<ArrivalsResponse>(
+                    API_ENDPOINTS.BUS.ARRIVALS
+                );
+                return data ?? null;

처럼 null 병합 연산자를 사용하면, 혹시나 나중에 ArrivalsResponse가 빈 문자열 같은 다른 falsy 값으로 확장되더라도 의도치 않게 null로 처리되는 일을 막을 수 있어 조금 더 안전합니다.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: KwonDeaGeun
Repo: KwonDeaGeun/WhatTheBus-Web PR: 21
File: src/App.tsx:16-23
Timestamp: 2025-09-22T04:45:54.455Z
Learning: KwonDeaGeun은 TypeScript에서 any 타입 사용을 피하고 더 타입 안전한 코드를 선호한다.

src/utils/mapOverlays.ts (1)

3-3: Shuttle 기반으로 오버레이를 키잉하도록 변경된 점이 타입과 일관적입니다.

Shuttle 타입을 도입해 createBusOverlays(map, buses: Shuttle[]) 시그니처와 캐시 키(bus.shuttleId)가 맞춰진 부분 좋습니다. Shuttle.shuttleId가 항상 유효한 값으로 들어온다는 전제가 있다면, ${bus.lat}-${bus.lng} fallback 이 실제로 필요한지(또는 assert 로 바꿀지) 한 번 더 정리해 두면 의도가 더 명확해질 것 같습니다.

Also applies to: 285-310

src/hooks/useBusSelection.ts (1)

2-2: Shuttle[] 기반 선택 로직으로의 타입 정리가 자연스럽습니다.

buses: Shuttle[]로 바뀌어 위치/방향 필드 사용이 명시적이고, 상위 useBusLocations 결과와도 타입이 잘 맞습니다. idx = n - 1는 UI에서 항상 1부터 시작하는 입력을 전제로 하므로, 방어적으로 1 ≤ n ≤ buses.length 범위 체크를 추가해 두면 추후 호출부 변경에도 더 안전할 것 같습니다.

Also applies to: 6-6, 11-36

src/types/bus.ts (1)

1-23: 셔틀·도착 정보 타입 정의가 직관적이고 null 가능성이 잘 표현되어 있습니다.

API 응답 형태를 Shuttle, ArrivalBus, ArrivalStop, ArrivalsResponse로 구분해 둔 덕분에 각 계층 책임이 명확하고, minutesLeft/remainingSeats의 null 여부도 타입에서 잘 드러납니다. 나중에 클라이언트 내부 도메인 모델을 더 풍부하게 가져가고 싶다면(예: updatedAt을 Date로 파싱한 뷰 모델 등) 이 파일의 원본 응답 타입과 별도의 도메인 타입을 분리해 두는 것도 고려해 볼 만합니다.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

Learnt from: KwonDeaGeun
Repo: KwonDeaGeun/WhatTheBus-Web PR: 21
File: src/App.tsx:16-23
Timestamp: 2025-09-22T04:45:54.455Z
Learning: KwonDeaGeun은 TypeScript에서 any 타입 사용을 피하고 더 타입 안전한 코드를 선호한다.